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Abstract — The  Core-Assisted  Mesh  Protocol  (CAMP)  is  introduced  for  multicast 
routing  in  ad-hoc  networks.  CAMP  generalizes  the  notion  of  core-based  trees  intro¬ 
duced  for  internet  multicasting  into  multicast  meshes  that  have  much  richer  connec¬ 
tivity  than  trees.  A  shared  multicast  mesh  is  defined  for  each  multicast  group;  the 
main  goal  of  using  such  meshes  is  to  maintain  the  connectivity  of  multicast  groups 
even  while  network  routers  move  frequently.  CAMP  consists  of  the  maintenance  of 
multicast  meshes  and  loop-free  packet  forwarding  over  such  meshes.  Within  the  mul¬ 
ticast  mesh  of  a  group,  packets  from  any  source  in  the  group  are  forwarded  along 
the  reverse  shortest  path  to  the  source,  just  as  in  traditional  multicast  protocols  based 
on  source-based  trees.  CAMP  guarantees  that,  within  a  finite  time,  every  receiver  of 
a  multicast  group  has  a  reverse  shortest  path  to  each  source  of  the  multicast  group. 
It  uses  cores  only  to  limit  the  traffic  needed  for  a  router  to  join  a  multicast  group; 
the  failure  of  cores  does  not  stop  packet  forwarding  or  the  process  of  maintaining  the 
multicast  meshes. 

I.  Introduction 

With  few  exceptions,  the  methods  used  today  for  supporting  many- 
to-many  communication  (multicasting)  efficiently  in  computer  net¬ 
works  involve  routing  trees.  The  basic  approach  consists  of  establishing 
a  routing  tree  for  a  group  of  routing  nodes  (routers).  Once  a  routing  tree 
is  established  for  a  group  of  routers,  a  packet  or  message  sent  to  all  the 
routers  in  the  tree  traverses  each  router  and  link  in  the  tree  only  once. 
Multicast  routing  trees  (multicast  trees  for  short)  are  being  used  exten¬ 
sively  for  multicast  routing  in  computer  networks  and  internets  [1],  [8], 
[9],  and  have  also  been  proposed  for  wireless  multi-hop  networks  [2], 
[4]. 

The  topology  of  an  ad-hoc  network  can  be  very  dynamic  due  to 
the  mobility  of  routers  and  the  characteristics  of  the  radio  channels. 
Although  tree-based  multicast  routing  is  very  attractive  for  wired  net¬ 
works  and  the  Internet  because  of  its  simplicity,  we  argue  that  it  is  not 
as  applicable  to  ad-hoc  networks  with  dynamic  topologies.  Maintaining 
a  routing  tree  for  the  purposes  of  multicasting  packets  when  the  under¬ 
lying  topology  changes  frequently  can  incur  substantial  control  traffic. 
This  paper  focuses  on  multicast  communication  in  ad-hoc  networks  and 
presents  a  generalization  of  routing  trees  into  graphs  that  have  more 
connectivity  than  trees  and  yet  prevent  long-term  or  permanent  routing 
loops  from  occurring.  We  call  these  routing  graphs  multicast  meshes. 
The  key  contributions  of  this  paper  consist  of  proving  that  it  is  pos¬ 
sible  to  establish  and  maintain  routing  structures  for  multi-point  com¬ 
munication  in  an  ad-hoc  network  that  are  far  more  resilient  than  trees 
and  can  make  efficient  use  of  communication  resources,  without  the 
need  to  first  flood  an  entire  network  or  internet  with  either  data  packets 
(like  DVMRP  or  PIM-DM  do),  or  control  packets  (like  the  Forwarding 
Group  Multicast  Protocol  (FGMP)  does  [3]). 

Section  II  introduces  the  main  design  principles  of  the  Core- Assisted 
Mesh  Protocol  (CAMP),  which  builds  and  maintains  shared  multicast 
meshes,  and  routes  packets  from  any  group  source  over  the  shortest 
from  source  to  receivers  defined  in  the  group’s  mesh.  Section  III  to 
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IV  describe  in  more  detail  the  creation  and  maintenance  of  multicast 
meshes  in  CAMP.  Section  V  describes  the  results  of  simulation  ex¬ 
periments  used  to  study  CAMP’s  performance  compared  to  tree-based 
multicasting  and  a  different  mesh  approach  in  a  dynamic  topology.  Sec¬ 
tion  VI  provides  our  concluding  remarks. 

II.  Overview  oe  CAMP 

CAMP  [II]  differs  from  most  prior  multicast  routing  protocols  in 
that  it  builds  and  maintains  a  multicast  mesh  for  information  distribu¬ 
tion  within  each  multicast  group.  A  multicast  mesh  is  a  subset  of  the 
network  topology  that  provides  at  least  one  path  from  each  source  to 
each  receiver  in  the  multicast  group.  CAMP  ensures  that  the  shortest 
paths  from  receivers  to  sources  (called  reverse  shortest  paths)  are  part 
of  a  group’s  mesh.  Packets  are  forwarded  through  the  mesh  along  the 
paths  that  first  reach  the  routers  from  the  sources,  i.e.,  the  shortest  paths 
from  sources  to  receivers  that  can  be  defined  within  the  mesh.  CAMP 
does  not  predefine  such  paths  along  the  mesh.  A  router  keeps  a  cache  of 
the  identifiers  of  those  packets  it  has  forwarded  recently,  and  forwards 
a  multicast  packet  received  from  a  neighbor  if  the  packet  identifier  is 
not  in  its  cache.  The  key  difference  between  a  mesh  and  a  tree  structure 
is  how  data  packets  are  accepted  to  be  processed.  A  router  is  allowed 
to  accept  unique  packets  coming  from  any  neighbor  in  the  mesh,  as  op¬ 
posed  to  trees  where  a  router  can  only  take  packets  coming  from  routers 
with  whom  a  tree  branch  has  been  established.  Therefore,  keeping  the 
branch  information  updated  is  one  extra  challenge  protocols  based  on 
trees  have  to  face  in  a  mobility  scenario. 

Because  a  member  router  of  a  multicast  mesh  has  redundant  paths  to 
any  other  router  in  the  same  mesh,  topology  changes  are  less  likely  to 
disrupt  the  flow  of  multicast  data  and  to  require  the  reconstruction  of  the 
routing  structures  that  support  packet  forwarding.  Figure  1  illustrates 
the  differences  between  a  multicast  mesh  and  the  corresponding  shared 
multicast  tree;  routers  that  are  members  of  the  multicast  group  are  dark. 
The  multicast  mesh  and  tree  shown  in  the  figure  include  routers  that 
have  host  receivers,  hosts  that  are  senders  and  receivers,  and  routers 
that  act  only  as  relays.  Router  g  is  the  last  receiver  to  join  the  multicast 
group,  and  does  so  in  the  multicast  mesh  through  either  router  /  or  /i; 
consequently,  router  c  does  not  become  a  member  of  the  mesh. 

CAMP  extends  the  basic  receiver-initiated  approach  introduced  in 
the  core-based  tree  (CBT)  protocol  [  1  ]  for  the  creation  of  multicast  trees 
to  enable  the  creation  of  multicast  meshes.  Cores  are  used  to  limit  the 
control  traffic  needed  for  receivers  to  join  multicast  groups.  In  contrast 
to  CBT,  one  or  multiple  cores  can  be  defined  for  each  mesh,  cores  need 
not  be  part  of  the  mesh  of  their  group,  and  routers  can  join  a  group  even 
if  all  associated  cores  become  unreachable. 

A  host  first  determines  the  address  of  the  group  it  needs  to  join  as  a 
receiver.  The  host  then  uses  that  address  to  ask  its  attached  router  to  join 
the  multicast  group  using  IGMP  [7].  Upon  receiving  a  host  request  to 
join  a  group,  the  router  sends  a  join  request  towards  a  core  if  none  of  its 
neighbors  are  members  of  the  group;  otherwise  it  simply  announces  its 
membership  using  either  reliable  or  persistent  updates.  If  cores  are  not 
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Fig.  1 .  Traffic  flow  from  router  /i  in  a  multicast  mesh  (left)  and  in  the  equivalent  multicast 

shared  tree  (right). 

reachable  from  a  router  that  needs  to  join  a  group,  the  router  broadcasts 
its  Join  request  using  an  expanded  ring  search  (ERS)  that  eventually 
reaches  some  group  member.  When  one  or  multiple  responses  are  sent 
back  to  the  router,  it  chooses  any  of  these  responses  to  use  as  a  path  to 
the  mesh.  The  mappings  of  multicast  addresses  to  (one  or  more)  core 
addresses  are  disseminated  from  each  core  out  to  the  network  as  part  of 
group  membership  reports. 

The  Core-Assisted  Multicast  Routing  Protocol  provides  also  an  al¬ 
ternate  way  for  routers  connected  to  sender-only  hosts  to  join  the  mesh. 
Whenever  a  router  senses  multicast  packets  originated  at  a  host  directly 
attached  to  it,  this  designated  router  will  join  the  mesh  in  simplex  mode 
if  it’s  not  a  member  yet.  The  simplex  join  request,  just  as  a  regular 
duplex  join  request,  will  travel  towards  one  of  the  available  cores  and 
is  acknowledged  in  the  same  fashion.  The  conceptual  difference  is  that 
data  packets  should  travel  in  only  one  direction:  from  the  sender-only 
host  to  the  mesh  and  not  the  opposite.  This  is  an  attempt  to  contain 
data  traffic  closer  to  the  areas  of  the  mesh  where  receivers  are  present. 
A  router  can  leave  the  group  when  there  are  no  other  hosts  or  routers 
depending  on  it  simply  by  advertising  the  change  in  group  member¬ 
ship  to  their  neighbors.  More  details  about  simplex  joins  as  well  as  the 
handling  of  topology  changes  are  presented  in  previous  work  [11]. 

A  router  leaving  a  multicast  group  issues  a  quit  notification  to  its 
neighbors,  who  in  turn  can  update  their  data  structures.  No  acknowl¬ 
edgments  are  requested  for  quit  notifications,  because  in  contrast  to 
multicast  routing  trees,  multicast  meshes  do  not  dictate  the  paths  taken 
by  multicast  packets.  Quit  notifications  are  sent  as  part  of  multicast 
routing  updates. 

The  Forwarding  Group  Multicast  Protocol  (FGMP)  [3]  and  the  On- 
demand  Multicast  Routing  Protocol  (ODMRP)  [13]  also  build  a  varia¬ 
tion  of  meshes.  However,  to  establish  group  meshes,  they  require  for 
control  packets  to  be  flooded  in  an  ad-hoc  network.  The  difference  be¬ 
tween  these  two  protocols  is  who  starts  the  flooding  —  in  the  former, 
the  receivers,  and  in  the  latter,  the  senders.  This  approach  is  accept¬ 
able  only  in  small  networks.  In  contrast,  the  use  of  cores  in  CAMP 
eliminates  the  need  for  flooding,  unless  all  cores  are  unreachable  from 
a  connected  component. 

III.  Routing  Information  and  Data  Forwarding  in  CAMP 

Each  router  maintains  a  routing  table  (RT)  built  with  the  unicast  rout¬ 
ing  protocol.  This  table  is  also  modified  by  CAMP  when  multicast 
groups  need  to  be  inserted  or  removed.  CAMP  assumes  the  existence 
of  a  beaconing  protocol,  usually  embedded  into  the  unicast  routing  pro¬ 
tocol  or  available  as  a  separate  network  service. 

At  router  i,  the  RT  made  available  to  CAMP  specifies,  for  each  des¬ 
tination  j,  the  successor  (sj)  and  the  distance  to  the  destination  (Dj). 

Other  than  the  unicast  routing  table,  CAMP  relies  on  these  data 
structures: 

•  CAM?  :  table  mapping  cores  to  multicast  groups. 


•  CORESg  :  set  of  routers  acting  as  cores  to  multicast  group  g. 

•  CACHEi  :  cache  of  multicast  data  packet  control  information. 

•  M RTi  :  the  multicast  routing  table,  containing  the  set  of  groups 
known  to  router  i. 

•  AT?  :  table  containing  anchor  information  pertaining  to  router  i. 
This  table  is  split  in  two  subsets: 

-  A?  :  list  of  neighbors  that  have  router  i  as  their  anchor  for  mul¬ 

ticast  group  g. 

-  A2?  :  list  of  neighbors  who  are  anchors  to  router  i  in  multicast 

group  g. 

•  N?  :  router  i’s  list  of  neighbors  that  are  known  to  be  members  of 
the  multicast  group  g. 

•  LS?  :  list  of  senders  that  are  directly  attached  to  router  i  and  send 
data  traffic  to  multicast  group  g. 

•  LR?  :  list  of  receivers  directly  attached  to  router  i,  who  want  to 
receive  data  packets  from  multicast  group  g. 

•  PEND?  :  list  of  either  join  or  simplex  join  requests  to  multicast 
group  g  originated  at  or  forwarded  by  router  i  for  whom  acknowl¬ 
edgment  is  pending. 

•  PEN  DP, J?  :  list  of  push  join  requests  to  multicast  group  g  orig¬ 
inated  at  or  forwarded  by  router  i  for  whom  acknowledgment  is 
pending. 

•  BK?  :  list  used  for  periodic  “book-keeping”  of  senders  and  asso¬ 
ciated  anchors. 

The  packet-forwarding  cache  CACHEi  maintains  information  of 
packets  recently  processed  by  router  i.  The  main  role  of  the  packet 
forwarding  cache  is  to  avoid  packet  replication  by  keeping  track  of 
packets  already  received  by  the  router.  Caching  packets  is  only  fea¬ 
sible  for  low-bandwidth  channels.  Although  restricted  to  symmetric 
networks,  an  alternative  to  packet  caching  is  the  use  of  reverse  path 
forwarding  [6],  where  routers  only  accept  data  packets  from  their  suc¬ 
cessor  to  the  packet  source. 

The  table  ATi  has  an  entry  for  each  of  the  multicast  groups  in  which 
router  i  is  a  member.  For  each  multicast  group  g,  an  entry  in  the  AT 
specifies  those  neighbors  that  router  i  uses  as  its  anchors  for  the  group, 
and  whether  the  router  has  any  local  host  that  is  a  source  or  receiver 
of  the  group.  An  anchor  for  router  i  in  group  p  is  a  neighbor  router 
that  is  a  successor  (next  hop)  in  the  reverse  shortest  path  to  at  least  one 
source  in  the  group  g.  Therefore,  a  router  determines  its  anchor  to  a 
given  source  by  using  the  unicast  routing  table.  In  the  example  shown 
in  Figure  1,  router  /  uses  router  g  as  an  anchor  for  the  group  because 
of  source  h,  if  g  is  the  next  hop  to  h  in  RT.  Note  that  a  router  does  not 
maintain  anchor  information  for  each  source  in  a  group. 

When  M RT  or  ATi  is  updated,  router  i  sends  a  multicast  routing 
update  (MRU)  to  all  its  neighbors  reporting  changes  in  its  group  mem¬ 
bership  and  anchors  per  group.  An  MRU  contains  one  or  more  entries, 
and  each  entry  specifies  a  multicast  group  address,  an  op-code  (quit  no¬ 
tification  or  duplex/simplex  membership  notification)  and,  when  update 
includes  a  membership  notification,  a  list  of  anchors  the  router  depends 
on  for  this  multicast  group.  The  main  objective  of  communicating  an¬ 
chor  information  among  routers  is  to  prevent  routers  that  are  required 
by  their  neighbors  to  forward  multicast  packets  from  leaving  groups 
prematurely. 

Detecting  the  failure  or  addition  of  a  link  to  a  neighbor  is  part  of 
the  routing  protocol  used  in  conjunction  with  CAMP.  For  CAMP  to 
work  correctly,  it  is  necessary  for  the  associated  routing  protocol  to 
work  correctly  in  the  presence  of  router  failures  and  network  partitions. 
This  implies  that  CAMP  cannot  be  used  in  conjunction  with  a  routing 
protocol  based  on  the  distributed  Bellman-Ford  algorithm  such  as  the 
routing  protocol  of  the  DARPA  packet  radio  network  [14].  However, 
there  are  several  recent  examples  of  routing  protocols  that  can  be  used 


in  conjunction  with  CAMP  [5],  [15],  [16]. 

The  basic  packet  forwarding  scheme  in  CAMP  consists  of  trying  to 
forward  multicast  data  packets  along  the  paths  within  the  mesh  that 
first  reach  the  member  routers  from  the  sources.  A  router  receiving 
a  multicast  packet  without  errors  from  a  neighbor  router  accepts  the 
packet  only  if: 

•  The  router  is  a  member  of  the  multicast  group  specified  in  the 
packet,  which  is  determined  from  the  router’s  MRT. 

•  If  the  router  is  a  duplex  router,  the  packet’s  sequence  number  is 
not  in  the  packet-forwarding  cache. 

•  if  a  simplex  router,  the  packet’s  sequence  number  is  not  in  the 
packet-forwarding  cache  and  the  neighbor  sending  the  packet  is 
also  a  simplex  router. 

When  a  router  accepts  a  packet,  it  adds  its  sequence  number  and 
the  identifier  of  the  source  to  its  packet  forwarding  cache.  This  step 
prevents  the  same  packet  from  being  accepted  more  than  once  by  the 
router,  provided  that  the  entries  in  the  cache  persist  longer  than  the  time 
it  takes  for  packets  to  revisit  a  router. 

IV.  Heartbeats  and  Push  Joins 

CAMP  ensures  that  all  the  reverse  shortest  paths  between  sources 
and  receivers  are  part  of  a  group’s  mesh  by  means  of  heartbeat  and 
push  join  (PJ)  messages. 

Periodically,  every  single  entry  in  the  packet  forwarding  cache  is 
verified.  The  router  looks  up  its  RT  to  check  whether  the  neighbor 
that  relayed  the  packet  is  the  reverse  path  to  the  source  for  every  cache 
entry.  A  heartbeat  or  a  PJ  is  sent  towards  every  source  stored  in  the 
cache  that  had  the  number  of  packets  coming  from  the  reverse  path 
under  a  threshold. 

CAMP  determines  two  types  of  push  Join  acknowledgments  —  reg¬ 
ular  ACK,  sent  by  duplex  members  and  ACK_SIMPLEX,  sent  by  sim¬ 
plex  members.  Given  the  fact  that  simplex  mesh  members  do  not  ac¬ 
cept  packets  coming  from  duplex  members,  it’s  important  that  there’s 
no  interleave  of  duplex  and  simplex  routers  between  the  initiator  of  a 
push  join  request  and  the  router  directly  attached  to  the  source.  When 
acknowledgments  start  coming  back  from  the  source,  duplex  members 
will  always  send  regular  ACKs,  and  simplex  members  will  become  du¬ 
plex  when  they  receive  a  regular  ACK.  Therefore,  if  there’s  at  least  one 
duplex  mesh  member  in  the  path  from  initiator  to  the  source,  all  nodes 
from  that  duplex  member  all  the  way  to  the  initiator  must  become  du¬ 
plex  if  they’re  not  yet. 

V.  Pereormance  Comparison 
A.  Protocols  Used  for  Comparison 

In  large  ad-hoc  networks,  no  multicast  protocol  proposed  to  date 
that  is  based  on  sender-initiated  joining  is  scalable  with  the  number 
of  nodes  in  the  network  or  the  number  of  sources  and  groups  in  the 
network.  Examples  of  this  type  of  protocols  based  on  routing  trees  are 
DVMRP  and  PIM-DM;  an  example  of  this  type  of  protocols  based  on 
graphs  other  than  trees  is  EGMP  [2].  The  reason  that  these  protocols 
are  not  scalable  is  that  sources  must  flood  either  data  packets  or  control 
packets  to  all  the  network  in  order  to  establish  a  routing  structure.  If  the 
network  size  is  large,  or  the  number  of  groups  and  sources  per  group  is 
large,  this  approach  is  not  applicable. 

To  date,  CAMP  is  the  only  multicast  routing  protocol  not  based  on 
trees  that  avoids  flooding  of  data  or  control  packets  to  establish  the 
routing  structure  for  a  group.  Therefore,  for  comparative  purposes,  we 
implemented  a  simple  tree-based  protocol  that  can  be  used  to  capture 
all  the  features  of  the  main  tree-based  multicast  protocols  with  receiver- 
based  joining  proposed  or  implemented  to  date.  Also  implemented  was 


Fig.  2.  Network  topology  used  in  experiments:  Lines  connecting  nodes  indicate  the  initial 

tree  obtained  with  CBT,  all  routers  are  receivers  of  the  multicast  group,  Router  16  is  the 

core,  and  A  and  B  are  sources. 

the  On-demand  Multicast  Routing  Protocol  (ODMRP)  [13].  The  ob¬ 
jective  of  the  simulation  experiments  is  to  illustrate  that  the  mesh  ap¬ 
proach  used  by  CAMP  is  more  robust  than  shared  tree  structures  and 
is  more  scalable  than  the  flood-based  mesh  approach  used  in  ODMRP 
and  EGMP. 

We  implemented  a  shared-tree  multicast  routing  protocol  that  is  sim¬ 
ilar  to  CBT  in  that  it  uses  a  single  core  and  uses  that  tree  to  forward 
packets.  A  router  in  this  protocol,  which  we  denote  by  WTP  (wireless 
tree-based  protocol),  forwards  data  packets  only  when  they  come  from 
one  of  the  children  or  parent  of  the  router  in  the  tree  rooted  at  the  core. 
The  tree  maintenance  part  of  WTP  extends  the  conventional  shared-tree 
protocols  like  CBT  and  PIM-SM.  In  WTP,  a  router  re-establishes  its 
connection  to  the  tree  by  looking  for  a  new  parent  as  soon  as  it  detects 
that  its  previous  parent  has  moved  away. 

B.  Experiments 

The  interesting  aspects  for  performance  comparison  between  CAMP 
and  the  other  multicast  protocols  are  the  average  delays,  percentage  of 
packet  loss  incurred  due  to  node  mobility,  and  the  number  of  control 
packets  received  by  each  node.  The  percentage  of  packets  lost  at  a  re¬ 
ceiver  is  simply  the  amount  of  packets  sent  by  the  traffic  source  that  was 
not  seen  by  the  specific  receiver.  Therefore,  the  smaller  the  percentage 
is,  the  better  the  protocol  behaves.  Obviously,  the  average  packet  delay 
measured  at  each  receiver  excludes  lost  packets. 

We  ran  a  number  of  experiments  to  study  this  aspect  of  CAMP’s 
performance  and  to  compare  it  against  the  other  multicast  approaches. 
Figure  2  shows  the  topology  of  the  dynamic  network  used  in  the  simu¬ 
lations.  The  network  has  30  routers,  numbered  from  1  to  30,  and  two 
senders,  A  and  B.  The  solid  links  shown  in  the  diagram  illustrate  the 
initial  shared  tree  computed  dynamically  in  the  simulation.  The  dashed 
links  represent  the  connectivity  among  nodes.  All  nodes  in  the  simu¬ 
lation  of  the  multicast  routing  protocols  are  receivers.  In  CAMP,  this 
means  all  nodes  are  duplex  members.  Router  16  was  chosen  as  core  for 
all  simulations. 

Experiments  ran  for  350  seconds  and  the  same  conditions  were  ap¬ 
plied  to  the  simulation  runs  for  CAMP,  WTP  and  ODMRP;  specifically, 
the  same  number  of  packets  was  sent  from  the  given  source,  the  same 
pattern  of  router  mobility  was  applied,  and  the  same  MAC  and  routing 
protocols  were  used.  The  simulations  used  a  single  broadcast  chan¬ 
nel,  so  that  the  transmission  of  a  node  is  received  by  all  its  neighbors. 
The  floor  acquisition  multiple  access  (FAMA)  protocol[10]  was  used  to 
access  the  broadcast  channel,  and  the  wireless  internet  routing  protocol 
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Fig.  3.  Number  of  packets  lost  by  routers  when  15  nodes  are  mobile,  and  traffic  comes 

from  source  A,  directly  connected  to  the  core. 

(WIRP)  [12]  with  hop  count  as  distance  metric  was  used  to  generate  the 
unicast  routing-table  entries  at  routers  for  CAMP  and  WTP.  ODMRP 
does  not  need  a  unicast  routing  protocol.  Radio  links  are  bidirectional. 
The  timers  of  updates  in  CAMP  and  sender  advertisement  in  ODMRP 
determine  how  fast  the  network  adapt  to  topology  and  group  member¬ 
ship  changes.  They  are  both  set  to  three  seconds. 

A  number  of  experiments  were  run  regarding  mobility.  For  the  sake 
of  brevity,  the  results  will  be  illustrated  only  by  the  experiments  where 
15  routers  were  moving  through  the  network.  The  mobile  nodes  are 
routers  1,  3,  6,  7,  9,  10,  17,  18,  19,  20,  23,  25,  27,  28  and  30.  The 
speed  at  which  mobile  nodes  moved  randomly  in  all  simulations  was 
67.5  miles/hr  (30  meters/sec). 

In  the  experiments,  data  traffic  is  originated  either  by  source  A, 
which  is  directly  attached  to  the  core  (router  16),  or  by  both  source 
A  and  B,  which  is  attached  to  router  29.  In  the  experiments  where  the 
source  of  data  traffic  is  sender  A,  the  load  was  4  packets/second.  In  the 
experiments  where  both  senders  A  and  B  transmitted  packets,  each  one 
sent  2  packets/second  to  try  to  keep  the  same  number  of  data  packets  in 
the  network. 

Not  surprisingly,  WTP  was  the  protocol  that  performed  the  worst  in 
the  experiments.  Figure  3  shows  the  different  outcome  between  WTP 
and  the  mesh-based  protocols  regarding  packet  losses.  WTP  attempts 
to  reconnect  the  tree  as  soon  as  possible  every  time  a  router  loses  its 
parent  in  the  shared  tree.  Every  time  the  unicast  routing  protocol  warns 
WTP  about  a  neighbor  being  removed  from  the  unicast  routing  table, 
the  protocol  sends  a  join  request  to  the  new  successor  to  the  core,  trying 
to  re-establish  its  connection  to  the  tree.  The  same  trend  shown  in  Fig¬ 
ure  3  for  packet  losses  was  observed  in  all  experiments  we  ran.  In  such 
a  context,  the  comparison  of  average  packet  delays  between  the  shared- 
tree  protocol  and  the  mesh-based  protocols  cannot  be  made,  since  the 
averages  for  the  routers  running  WTP  is  computed  based  in  much  less 
data  packets  than  in  CAMP  and  ODMRP.  Therefore,  for  the  sake  of 
brevity,  we  do  not  include  WTP  results  in  the  following  figures. 

The  reason  for  the  poor  behavior  of  WTP  is  the  strong  dependency 
it  has  on  consistent  unicast  routing  tables  to  provide  a  loop-free  shared 
tree.  WIRP  [12],  the  unicast  routing  protocol  used  in  the  experiments, 
may  create  temporary  loops  shortly  after  links  go  down.  Because 
WTP  makes  decisions  regarding  tree  reconnection  shortly  after  links 
go  down,  the  shared  tree  becomes  vulnerable  to  loops,  which  leads  to 
the  larger  packet-loss  rate.  This  fact  shows  the  difficulties  brought  up 
when  packet  forwarding  is  dictated  by  a  strict  delivery  structure  like  a 
shared  tree  in  a  dynamically  changing  environment.  Protocol  behavior 
in  the  presence  of  temporary  loops  in  unicast  routing  also  illustrates  the 
survivability  of  mesh  protocols. 

Figures  4  and  5  summarize  the  comparison  between  CAMP  and 
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Fig.  4.  Average  packet  delay  (a),  number  of  incoming  control  packets  (b)  and  percentage 
of  missed  data  packets  (c)  for  routers  in  a  network  of  30  nodes,  where  15  of  these  nodes 
are  mobile.  Data  traffic  from  source  A,  which  is  the  one  close  to  the  core. 

ODMRP  over  the  different  experiments  we  have  run.  Dotted  lines  rep¬ 
resent  ODMRP  and  solid  ones  represent  CAMP.  Figure  4(a)  shows  that 
CAMP  renders  smaller  delays  than  ODMRP  in  the  case  of  a  single 
source  sending  4  packets/second  and  15  nodes  moving  in  the  network. 
And  the  main  reason  for  this  difference  in  average  is  shown  in  Fig¬ 
ure  4(b).  The  longer  delays  incurred  in  ODMRP  is  a  consequence  of 
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Fig.  5.  Average  packet  delay  (a),  number  of  incoming  control  packets  (b)  and  percentage  of 
missed  data  packets  (c)  for  routers  in  a  network  of  30  nodes,  where  15  of  these  nodes  are 
mobile.  Data  traffic  from  both  sources  A  and  B.  In  this  figure,  “CAMP- A”  represents 
the  results  for  routers  running  CAMP  due  to  traffic  from  Source  A. 

the  flooding  of  control  packets  per  source  needed  in  ODMRP.  The  num¬ 
ber  of  control  packets  received  by  CAMP  routers  is  just  a  small  frac¬ 
tion  of  the  number  seen  by  ODMRP  routers.  For  the  same  traffic  load 
and  mobility  patterns,  both  protocols  perform  similarly,  when  there’s 
one  source  of  data  traffic,  as  shown  by  Figure  4(c).  As  the  number  of 


sources  grows,  CAMP  performs  even  better  than  ODMRP,  as  shown  in 
Figure  5.  In  Figure  5(a),  one  can  observe  that,  like  routers  1,  2  and  3, 
almost  half  of  the  routers  in  the  network  show  shorter  delays  for  both 
senders  A  and  B  when  running  CAMP.  As  illustrated  by  Figure  5(c), 
as  far  as  packet  losses  are  concerned,  CAMP  loses  consistently  fewer 
packets  when  more  than  one  source  send  data  packets.  Those  aspects 
of  the  protocols’  performance  illustrate  that  meshes  can  be  used  effec¬ 
tively  as  multicast  routing  structures  without  the  need  for  flooding  of 
control  packets. 

VI.  Conclusions 

We  have  introduced  the  first  multicast  routing  protocol  based  on  a 
routing  structure  other  than  trees  that  does  not  require  flooding  an  en¬ 
tire  network  with  control  or  data  packets  to  set  up  its  routing  structure. 
CAMP  consists  of  the  maintenance  of  multicast  meshes  and  loopless 
packet  forwarding  over  such  meshes.  Within  the  multicast  mesh  of  a 
group,  packets  from  any  source  in  the  group  are  forwarded  along  the 
shortest  paths  defined  with  the  mesh  from  the  source  to  the  receivers. 
Simulation  experiments  show  that  mesh-based  protocols  easily  outper¬ 
form  tree-based  multicast  protocol  in  dynamic  networks.  Experiments 
show  that  CAMP  scales  very  well,  because  it  does  not  require  sources 
or  receivers  to  flood  the  entire  network  with  control  or  data  packets  as 
long  as  there  are  cores  available.  Our  comparison  with  ODMRP  shows 
that  the  receiver-initiated  approach  used  for  mesh  joining  in  CAMP 
performs  and  scales  better  than  the  sender-initiated  approach. 
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